home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group94a.txt / 000142_icon-group-sender _Sat May 7 17:33:23 1994.msg < prev    next >
Internet Message Format  |  1994-08-19  |  4KB
  1. Received: by cheltenham.cs.arizona.edu; Tue, 24 May 1994 20:10:59 MST
  2. Path: ucbvax!cis.ohio-state.edu!math.ohio-state.edu!darwin.sura.net!udel!rochester!rit!nmw1638
  3. From: nmw1638@cs.rit.edu (Nicolas M Williams)
  4. Newsgroups: comp.lang.icon
  5. Subject: Re: Regular expressions & dynamic linking (was Re: Spitbol vs. Icon)
  6. Message-Id: <1994May7.173323.3010@cs.rit.edu>
  7. Date: 7 May 94 17:33:23 GMT
  8. References: <CpC86B.K2C@stortek.com> <1994May5.223307.19549@cs.rit.edu> <CpDx7B.H1o@stortek.com>
  9. Sender: news@cs.rit.edu (USENET News Admin)
  10. Organization: Rochester Institute of Technology, Rochester, NY
  11. Lines: 76
  12. Nntp-Posting-Host: iowa
  13. Apparently-To: icon-group@cs.arizona.edu
  14. Status: R
  15. Errors-To: icon-group-errors@cs.arizona.edu
  16.  
  17. In article <CpDx7B.H1o@stortek.com> cheyenne@witsend.stortek.com (Cheyenne Wills) writes:
  18. >In <1994May5.223307.19549@cs.rit.edu>, nmw1638@cs.rit.edu (Nicolas M Williams) writes:
  19. >>In article <CpC86B.K2C@stortek.com> cheyenne@witsend.stortek.com (Cheyenne Wills) writes:
  20.  
  21. >Hmmm.... well...
  22. >One of Icon's design goals was (is) to provide a language that is
  23. >fairly easily read.  While one can write unreadable code in any language,
  24. >some languages lend themselves to being more unreadable then others.
  25.  
  26. Heh, sure, look, there are single characters that have a lot of meaning
  27. in Icon, where their meaning depends on the situation (e.g. / and \).
  28. Plus recursive generators can be hard to figure out. No, Icon can be
  29. very cryptic, which I in particular don't mind very much, after all, I'm
  30. used to C and awk and sed and....
  31.  
  32. >Regular expressions are themselves a fullblown language, they have
  33. >their place.
  34.  
  35. They can complement Icon, see below.
  36.  
  37. >I'm not saying that adding regular expressions to Icon is bad (or good),
  38. >I'm just tring to say that with Icon, one can achive the same end result
  39. >with existing facilities.  In addition, Icon provides some facilities
  40. >that just are not possible under regexps (try extracting "balanced
  41. >strings" -- "(3+4*(5+6)*(10+11))".  With regexps the best you can do
  42. >with the above is:  "(3+4*(5+6)".
  43.  
  44. Right, now imagine (I haven't seen the regexp library yet) a function
  45. that returns the position of the subject string that marks the first
  46. character of a string matched by a regexp, and another function that
  47. returns the last character of said string provided you give it the
  48. position of the first character of the matched string. That would fit in
  49. quite well into the string scanning environment of Icon. I want regexps
  50. not because they are good enough (which they are not), but because they
  51. can simplify a lot of tasks.
  52.  
  53. >    In addition a programmer can extend
  54. >string pattern matching with their own functions, something that one
  55. >cannot do with regexps.  Once a useful pattern matching function
  56. >has been built, one can save it for use later without having to
  57. >reinvent it all over.  If I need a pattern to match labels, I have
  58. >an Icon function already coded that will do that.  If I need a pattern
  59. >to match "real numbers", I already have that, etc.
  60.  
  61. Yes, indeed, I have done this. So? Replacing a well commented regexp is
  62. not that hard; I've done that too.
  63.  
  64. >Maintainability is always an issue.  Even "throw-a-way" code has a
  65. >tendancy to live a life longer then the author may have intended.
  66.  
  67. Yes, but regexps are seldom huge (several lines long), and if their
  68. actions are well commented, replacing that regexp with another one is
  69. not very hard. Yes, there is a maintainability issue, but I claim that
  70. it is not crucial, not as crucial as the maintainability of pages of C
  71. (or Icon for that matter) code.
  72.  
  73. >regexp "package" in the Icon Program Library.
  74.  
  75. Ok, I'd never been able to find the Icon libs, but I just did (archie
  76. IPL), so I'll be looking through that as soon as I can get the time.
  77.  
  78. >Cheyenne
  79.  
  80. >+--------------------------------------+---------------------------------+
  81. >| +-----+                   | Cheyenne Wills          |
  82. >| |    |      "From here on up it is  | Storage Technology Corporation  |
  83. >| |  +--+--+     downhill all the way" | 2270 South 88th St.             |
  84. >| |  |    |  |                   | Louisville, Co. 80028-4232     |
  85. >| +--+--+  |   These are not the       |                 |
  86. >|    |       |   opinions or views of    | Cheyenne_Wills@stortek.com     |
  87. >|    +-----+   Storage Technology      | cheyenne@witsend.stortek.com     |
  88. >+--------------------------------------+---------------------------------+
  89. >
  90.  
  91.  
  92. Nick
  93.